Policy information in multiple PDFs

ABSTRACT

The invention proposes a method for establishing sessions in a network comprising a user entity, a network control node and a plurality of network nodes storing subscriber specific information, the method comprising the steps of receiving a session establishing request at the network control node, forwarding a policy request message from the network control node to each network node of the plurality of network nodes storing subscriber specific information comprising policy information required for the session to be established, processing the policy request message to generate a policy decision message and sending the policy decision message to the network control node from each of the network nodes having received the policy request message, generating a single policy decision confirmation message based on the received policy decision messages in the network control node, and sending the single policy decision message to the user entity.

This is a continuation application of U.S. patent application Ser. No.10/757,435, filed on Jan. 15, 2004, which claims the benefit of priorityof provisional application Ser. No. 60/448,491, filed Feb. 21, 2003, thecontents of which are incorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates to a method and a network element forhandling policy information in multiple network nodes storing subscriberspecific information, e.g., PDF (Policy Control Functions or PolicyDecision Functions, also abbreviated as PCF).

BACKGROUND OF THE INVENTION

As described above, the present invention relates to handling of policyinformation. Such a handling is necessary in case a user would like toestablish a session (e.g., a multimedia session) in which for theestablishment additional information are required. Such additionalinformation could be, for example, services required for the session,addresses of particular servers necessary for the session, informationregarding handling of the session or whether the user is entitled to usethe corresponding services necessary for the session. Moreover, alsocharging and/or billing information can be included.

The handling of policy information is carried out in a Policy ControlFunction (PDF). This is a logical policy decision element that usesstandard IP (Internet Protocol) mechanisms to implement policy in the IPmedia layer. The PDF makes decisions in regard to network based IPpolicy using policy rules, and communicates these decisions to a GGSN(Gateway GPRS Support Node, GPRS=General Packet Radio Service), whichserves the UE (user entity) of the user/subscriber. In detail, thedecisions are communicated to a Policy Enforcement Point (PEP) locatedin the GGSN. This is a logical entity that enforces policy decisionsmade by the PDF. Between the GGSN and the PDF, a so-called Go interfaceis defined. Further details on PDF and policy control over Go interfacecan be found in ETSI TS 29 207 V5.0.0 (2002-06), for example.

In the following, a session authorization mechanism carried out onestablishing a session is described briefly.

When a UE wishes to establish a session, it sends a set-up request(e.g., SIP INVITE) to the P-CSCF. This set-up request indicates e.g.,the media streams to be used. The P-CSCF sends the necessary informationto the PDF which makes a decision on the request, i.e., authorizes thesession or does not authorize the decision. This decision is included ina response called “authorization token” which is subsequently used bythe PDF in order to identify the session and the media it hasauthorized.

The P-CSCF sends a corresponding response to the UE which includes adescription of the negotiated media together with the authorizationtoken from the PDF. After this, the UE issues a request (for example, aPDP context activation) to reserve the resources necessary to provide arequired QoS (Quality of Service) for the media stream. In this request,the authentication token from the PDF provided via the PDF and FlowId(s) (flow identifier(s)) identifying the flow(s) on the PDP contextare included.

The GGSN receives the reservation request and sends a policy decisionrequest to the PDF in order to determine if the resource request shouldbe allowed to proceed. Included in this request are the authenticationtoken and the Flow Id(s) provided by the UE. The PDF uses thisauthorization token and the Flow Id(s) in order to correlate the requestfor resources with the media authorization previously provided to theP-CSCF. After this, the PDF sends a decision to the GGSN. Then, the GGSNsends a response to the UE indicating that the resource reservation iscomplete. Thus, the session can be started.

As to the function of the Authorization Token and the Flow Id(s), it isnoted that in 3GPP R5, the Authorization Token and Flow Id(s) are usedas binding information. The Authorization Token is also used to derivethe IP address of the PDF storing the policy information.

In 3GPP (Third Generation Partnership Project) R5 (Release 5), the PDFis part of a P-CSCF (Proxy Call Session Control Function). The P-CSCF isa network element providing session management services (e.g., telephonycall control).

In the next release, namely 3GPP R6, separating the PDF from the P-CSCFwill be studied. That is, in such an environment, the PDF is independentfrom the P-CSCF, as described in 3GPP TR 23.917V0.4.10 (2002-12), forexample. Therefore, a plurality of PDFs may be arranged, in order tohandle policies for different kinds of sessions, for example.

It is possible that in the future there is a N-M relation between theP-CSCF and the PDF, i.e., that there is a plurality of P-CSCF and aplurality of PDF related to each other. This N-M relation is already in3GPP R5 between the GGSN and the PDF. For the P-CSCF, this means that itcould send session information to many PDFs. This could be done eitheron session basis e.g. by using a simple round-robin mechanism. Or thenthe P-CSCF could consider the load of the PDFs and could send sessioninformation to the least loaded PDF. As an alternative, the P-CSCF couldalso send session information on UE basis, e.g. so that information onall sessions of a UE would be sent to the same PDF. And yet as anotheralternative, session information of roaming UEs could be sent to certainPDFs, whereas session information of home UEs would be sent to otherPDFs.

It is possible that in the future, the P-CSCF is served by one PDF andone PDF serves many P-CSCFs (1 to N relation). In that case, when the UEis served by many P-CSCFs for different application sessions, the sameproblems as described above may occur.

As described above, the PDF derives policy information from the receivedsession information. If session information of a UE may reside inmultiple PDFs, requesting policy information becomes more complex.

SUMMARY OF THE INVENTION

Thus, the object underlying the present invention resides in providing amechanism, by which in a system comprising a plurality of nodes storingspecific subscriber information (e.g., PDFs) an easy handling of policyinformation is possible.

This object is solved by a method for establishing sessions in a networkcomprising a user entity, a network control node and a plurality ofnetwork nodes storing subscriber specific information, the methodcomprising the steps of receiving a session establishing request at thenetwork control node, forwarding a policy request message from thenetwork control node to each network node of the plurality of networknodes storing subscriber specific information which comprise policyinformation required for the session to be established, processing thepolicy request message to generate a policy decision message and sendingthe policy decision message to the network control node from each of thenetwork nodes having received the policy request message, generating asingle policy decision confirmation message based on the received policydecision messages in the network control node, and sending the singlepolicy decision message to the user entity.

Thus, according to the invention, a network control element contacts aplurality of nodes storing subscriber specific information (e.g., PDFs).This network control element provides the contact with the user entity,such that only a single request message is required which includespolicy information for the plurality of nodes. Likewise, only a singledecision message is necessary which comprises all policy decisions ofthe plurality of nodes.

Hence, the handling of policy information from the viewpoint of the userentity is as simple as in the prior art, namely, only single messagesare required although now a plurality of nodes are provided.

That is, although the structure comprising a plurality of nodes storingsubscriber specific information (e.g., PDFs) is more complex that in theprior art according to which only one node is present, the handling ofthe policy information does not become complicated

The network control element may be itself a network node of theplurality of network nodes storing subscriber specific information. Thatis, one of the network nodes storing subscriber specific information(e.g., PDF) controls the other PDFs.

Alternatively, the network control element may be a network serviceelement serving the user entity. For example, the network serviceelement may be a GSGN.

If network control element may be itself a network node of the pluralityof network nodes storing subscriber specific information, the networkcontrol element may be selected by network connection serving elementserving the user entity. For example, a default network node storingsubscriber specific information may be selected. That is, for example aGSGN selects the one PDF of a plurality of PDFs.

The single policy decision message may comprise an authorization tokenfrom each node storing subscriber specific information. That is, allnecessary authorization tokens are sent in the single message, such thatno multiple messages for conveying the authorization tokens arerequired.

When the user entity is located in a visited operator domain, thefollowing steps may be carried out: inserting policy information into asession set-up protocol message, sending the session set-up protocolmessage to a network control element in the home domain of the userentity, forwarding the policy information to a home subscriber databasenode, extracting an address of a home node storing subscriber specificinformation of the user entity from the subscriber database node,creating home policy information based on the extracted address, andforwarding the home policy information to a network control element ofthe visited network.

In this way, also the situation can be handled that a subscriber isroaming. Namely, the necessary policy information are sent during asession set-up to a home subscriber database node, and a network controlelement of the visited network is provided with necessary information.

The policy information may comprise an authentication token in general,so that the created home policy information may comprises a homeAuthentication Token.

Furthermore, the network control element of the visited network maycreate a visited policy information. That is, when roaming, there mightbe two different kinds of policy information, namely home and visitedpolicy information.

The home policy information may be inserted into another session set-upprotocol message

The session set-up protocol used for the above-referenced session set-upmay be a Session Initiation Protocol (SIP).

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a block diagram illustrating the procedure according to afirst embodiment of the invention

FIG. 2 shows a block diagram illustrating the procedure according to asecond embodiment of the invention, and

FIG. 3 shows a signalling flow diagram illustrating the procedureaccording to a third embodiment of the invention.

DETAILED DESCRIPTION OF THE INVENTION

In the following, preferred embodiments are described by referring tothe enclosed drawings.

As described in the foregoing, the present invention is directed to thecase that a plurality of PDFs (as examples for nodes storing subscriberspecific information) are present which are independent from the P-CSCF.

According to a preferred embodiment of the invention, the GGSN contactsonly one PDF and this selected PDF then contacts other PDFs ifinformation on all sessions of a UE is not sent to the same PDF.

This situation is illustrated in the block diagram shown in FIG. 1. Itis noted that FIG. 1 only shows the principle necessary forunderstanding the invention, so that network elements required forestablishing a connection but which are not essential for describing theinvention are omitted for simplifying the illustration.

In detail, FIG. 1 shows a network system in which a plurality of PDFs(PDF(A), PDF(B), PDF(C), PDF(D)) are provided. In a message A1, the UErequests set-up of a session. Included in this message are a pluralityof Authorization Tokens for the multiple PDFs, and also Flow Id(s). TheGGSN takes only one of the Authorization Tokens (e.g. first or last) anddetermines the IP address of the PDF with that. In the illustrated case,it is assumed that the GGSN takes only the Authorization Token forPDF(A). The GGSN does not determine the IP addresses of the other PDFs(i.e., PDF(B), PDF(C) and PDF(D

The GGSN then sends a COPS (Common Open Policy Service) Request message(indicated by A2 in FIG. 2) to the selected PDF(A) with all the bindinginformation (in particular, including all Authorization Tokens) sent bythe UE to the GGSN. The PDF(A) takes the remaining Authorization Tokensand contacts the remaining PDFs in order to receive policy informationfrom those. That is, in the case as illustrated in FIG. 1, the PDF(A)contacts PDF(B), PDF(C) and PDF(D) in messages A3 to A5, respectively,and receives the policy information in messages A6 to A8, respectively

The remaining PDFs addresses of PDF(B), PDF(C) and PDF(D) can beconfigured in the PDF(A) or the PDF(A) can make a DNS query based on thePDF FQDN (Fully Qualified Domain Name). All the subsequent GGSN requestswill be sent to the PDF(A) and PDF(A) will trigger the request to theremaining PDFs. All the subsequent decisions from the PDFs will betriggered by the PDF(A) to the GGSN. Also the PDF(A) will trigger allthe GGSN reports regarding changes related to the IP flows (carried bythe PDP context) to the remaining PDFs.

In the present case, the policy decision is included in a message A9sent from the selected PDF(A) to the GGSN. The GGSN sends the policydecision to the UE in message A10.

Hence, the handling of policy information in a system comprising aplurality of PDFs according to the first embodiment of the invention isuncomplicated. In particular, the UE does only have to send a singleset-up request message in which all necessary Authorization Tokens areincluded. The GGSN does only have to contact one single PDF (i.e.,PDF(A) which handles the policy information with respect to the otherPDFs involved. The policy decision is again sent in a single messagefrom the PDF(A) to the GGSN and finally to the UE. Thus, the procedurefor obtaining a policy information is from the viewpoint of the UEalmost the same as according to the prior art: it requires only a singlemessage although a plurality of PDFs are involved.

According to a modification of the first embodiment, a default PDF isintroduced. The default PDF IP address is configured to the GGSN accesspoint basis. That is, the address of the default PDF is stored in theGGSN so that this address does not have to be derived fromAuthentication Tokens received from the UE, for example. The GGSN alwayscontacts this default PDF which then contacts the correct PDFs in orderto receive policy information from those. In this way, the load on theGGSN is reduced and only a single PDF has to perform contacting otherPDFs

That is, in case of the situation as illustrated in FIG. 1, PDF(A) couldbe such a default PDF. In this case, it is not necessary for the GGSN toderive the address of PDF(A) since it is already set as a default, andit is not necessary to process the corresponding Authentication Token inthe GGSN, which reduces the operation load on the GGSN.

Alternatively to the above, according to a second embodiment of thepresent invention, the GGSN contacts the multiple PDFs. That is, it ispossible for 3GPP R6 that the GGSN requests separate authorizationdecisions from the involved PDFs regarding the authorization of the IPflows associated with components from different application sessionscarried by a single PDP context

This situation is illustrated in FIG. 2. The system shown in FIG. 2 issimilar to that shown in FIG. 1 except that the GGSN contacts theplurality of PDFs and not a selected PDF. The message B1 by which the UErequests a session set-up is the same as the message A1.

In contrast to the first embodiment, the GGSN considers all of theavailable Authorization Tokens in the PDP context and determines ifdifferent PDFs are involved.

The GGSN makes a separate authorization request including the bindinginformation (the related Authorization Token and Flow Id(s)) to each ofthe concerned PDFs. This is illustrated in FIG. 2 by the messages B2 toB5, respectively. When the GGSN receives the authorization decisionsfrom the PDFs (illustrated by messages B6 to B9), then it combines theminto one authorization decision for the PDP context.

That is, the message B10 containing the authorization decision sent tothe UE is the same as the message A10 shown in FIG. 1.

Thus, according to the second embodiment, the GGSN handles contacting ofthe different PDFs. This reduces the load on the PDF, since, in contrastto the first embodiment, there is no selected PDF(A) or a default PDFwhich needs to comprise also a functionality of contacting the otherPDFs.

According to the first and the second embodiment described above, it isassumed that the PDFs reside in the same operator domain. In 3GPP R5,the PDF may reside either in the visited operator domain or in the homeoperator domain (depending on the GGSN location). In the future, i.e.,in 3GPP R6, if the PDF resides in the visited operator domain, it maywant to communicate with the PDF of the home operator domain (to receiveUE specific policies from the home operator domain).

Using the Authorization Token in order to determine the PDF of the homeoperator domain requires some changes to the current mechanism in caseof roaming UEs (i.e. UEs using the P-CSCF in the visited operatordomain). According to the prior art (as described in the introductorypart of the present application), the PDF in the P-CSCF allocates theAuthorization Token.

However, in the future, i.e., when P-CSCF and PDF are separated, theAuthorization Token may have to be allocated also in the home operatordomain (so that the PDF in the visited operator domain can contact thePDF in the home operator domain).

This situation is described in the following as a third embodiment. Itis noted that the way how the different PDF(s) located in the visitedoperator domain are accessed by the GGSN itself or the selected PDF(A)is the same as in the first embodiment and the second embodiment. In thepresent third embodiment, the creation of Authentication Tokens isdescribed which require access to a home domain PDF.

According to the third embodiment, a node in the home operator domainforwarding SIP messages (e.g. S-CSCF) inserts the Authorization Tokeninto the SIP messages (e.g., INVITE when establishing a session). TheAuthorization Token includes the PDF FQDN (Fully Qualified Domain Name).This PDF, i.e., the PDF in the home domain, stores UE specificinformation. In contrast thereto, the PDF(s) in the visited operatordomain stores only session based information. For a policy decision,information of both PDF(s) located in the home domain and PDF(s) locatedin the visited operator domain might be necessary.

If the S-CSCF includes the Authorization Token to SIP messages, theS-CSCF may get the PDF fully qualified domain name e.g. from the HSS asindicated in FIG. 3

FIG. 3 shows a principle structure how the Authentication Token iscreated. It is noted that only the network elements and the flownecessary for the invention are shown in order to simplify theillustration. The UE sends a SIP INVITE message to the P-CSCF of thevisited operator domain. The P-CSCF forwards the INVITE message to theS-CSCF of the home domain. The S-CSCF further processes and forwards thesession set-up (as indicated by the dotted arrow), in the following,however, only the creation of the authentication token is shown. TheS-CSCF sends a SIP REQUEST message to the HSS of the subscriber (UE).The HSS responds with a the PDF FQDN. Hence, the S-CSCF knows the PDFFQDN and creates the Authentication Token of the home PDF (abbreviatedas Auth Token (home) in FIG. 3) which includes the PDF FQDN. It is notedthat also a plurality of Authentication Tokens (home) may be created incase a plurality of PDFs are provided in the home domain which containrelevant information for the session to be established by the particularsubscriber.

Meanwhile, the S-CSCF receives a SIP ACK message during the remainingset-up of the session (as indicated by the dotted arrow). Thereafter,the S-CSCF inserts the Auth Token (home) into the SIP ACK message andforwards this to the P-CSCF in the visited operator domain. This P-CSCFalso creates an Authentication Token for the visited operator domain(abbreviated as Auth Token (visited) in FIG. 3). It is noted that also aplurality of Auth Tokens (visited) may be created in case a plurality ofPDFs in the visited operator domain are involved.

Finally, the P-CSCF inserts the created Auth Tokens (visited) into theSIP ACK messages and sends it to the UE. After this, the UE has receivedthe necessary Authentication Tokens both of the visited and home domainsuch that it can start a session

As an alternative, if the Authorization Token is not used to determinethe PDF in the home operator domain, the PDF in the visited operatordomain could perform a UE identity analysis (e.g. IMSI analysis) inorder to determine the PDF in the home operator domain

Thus according to the above embodiments, the GGSN can communicate withone PDF only and could receive policy information affecting an entity(e.g. a PDP context) from one network element (a selected PDF, a defaultPDF or the GGSN) only.

The above description and accompanying drawings only illustrate thepresent invention by way of example. Thus, the embodiment may varywithin the scope of the attached claims.

For example, the PDF as described in the above embodiments is just anexample for a node storing subscriber specific information in the homeoperator domain. HSS (Home Subscriber Server) is another example of sucha node. That is, also the HSS could be provided in such a structure thatdifferent HSS servers are provided. In this case, the AuthorizationToken includes the HSS FQDN instead of the PDF FQDN.

Moreover, the GGSN is only an example for a network service elementserving the user entity.

1. A method, comprising: receiving a policy request message at a firstnetwork node storing subscriber specific information which comprisepolicy information required for the session to be established;processing the policy request message to generate a policy decisionmessage in the first network node; forwarding a policy request messagefrom the first network node to at least one second network node storingsubscriber specific information which comprise policy informationrequired for a session to be established; processing the policy requestmessage to generate a policy decision message in the at least one secondnetwork node and sending the policy decision message to the firstnetwork node from the at least one second network node having receivedthe policy request message; generating a single policy decisionconfirmation message based on the received policy decision messages inthe first network node; and sending the single policy decision message.2. The method according to claim 1, further comprising selecting thefirst network node storing subscriber specific information by thenetwork connection serving element serving a user entity.
 3. The methodaccording to claim 2, wherein the first node is a default network nodestoring subscriber specific information.
 4. The method according toclaim 1, wherein the single policy decision message comprises anauthorization token from each node storing subscriber specificinformation.
 5. The method according to claim 1, wherein a user entityis located in a visited operator domain, and the method furthercomprising: inserting policy information into a session set-up protocolmessage; sending the session set-up protocol message to a networkcontrol element in the home domain of the user entity; forwarding thepolicy information to a home subscriber database node; extracting anaddress of a home node storing subscriber specific information of theuser entity from the subscriber database node; creating home policyinformation based on the extracted address; and forwarding the homepolicy information to a network control element of the visited network.6. The method according to claim 5, wherein the policy informationcomprises an authentication token, and the home policy informationcreated in the creating step comprises a home authentication token. 7.The method according to claim 5, further comprising: creating a visitedpolicy information in the network control element of the visitednetwork.
 8. The method according to claim 5, wherein in the forwarding,the home policy information is inserted into another session set-upprotocol message.
 9. The method according to claim 5, wherein thesession set-up protocol is a session initiation protocol (SIP).
 10. Themethod according to claim 1, wherein the network node storing subscriberspecific information is a policy control function (PDF).
 11. Anapparatus, comprising: a memory configured to store subscriber specificinformation comprising policy information required for a session to beestablished; a receiver configured to receive a session establishingpolicy request message; a processor configured to process the policyrequest message and to generate a policy decision; wherein the receiveris further configured to send a policy request message and to receive apolicy decision message in response to the sent policy request message;and a generator configured to generate a single policy decisionconfirmation message based on the received policy decision messages andthe policy decision generated by processor, and to send the singlepolicy decision message.
 12. The apparatus according to claim 11,wherein the receiver is configured to send the policy request message toat least one network node storing subscriber specific information whichcomprise policy information required for the session to be established,and to receive the policy decision message from this at least onenetwork node.
 13. The apparatus according to claim 11, wherein thesingle policy decision message comprises an authorization token fromeach node storing subscriber specific information.
 14. The apparatusaccording to claim 11, wherein the network node storing subscriberspecific information is a policy control function.
 15. A method,comprising: receiving a policy request message at a first network nodestoring subscriber specific information comprising policy informationrequired for a session to be established; processing the policy requestmessage to generate a policy decision message in the first network node;sending a policy request message receiving a policy decision message inresponse to the sent policy request message; and generating a singlepolicy decision confirmation message based on the received policydecision messages and the generated policy decision.
 16. The methodaccording to claim 15, wherein in sending the policy request message, atleast one policy request message is sent to at least one second networknode storing subscriber specific information which comprise policyinformation required for the session to be established, and in thereceiving, the policy decision message is received from the at least onenetwork node.
 17. The method according to claim 15, wherein the singlepolicy decision message comprises an authorization token from each nodestoring subscriber specific information.
 18. The method according toclaim 15, wherein the network node storing subscriber specificinformation is a policy control function.